Prior state and problem. When a project list contains a generator (e.g., explode) alongside transform(arr, x => struct(x.as("data"))), the resulting struct field comes out as col1 instead of data. Root cause is a timing interaction: ExtractGenerator runs at resolution-rule position 530, before ResolveFunctions (532), so the inner struct(...) is still UnresolvedFunction("struct", Seq(Alias(x, "data"))). The pre-PR code applied .map(trimNonTopLevelAliases) to the entire project list before pattern matching. trimAliases has a special case for CreateNamedStruct that preserves alias-carried metadata, but that case requires the expression to already be CreateNamedStruct -- while it is still UnresolvedFunction, the generic case other => other.mapChildren(trimAliases) branch descends into the lambda body and strips Alias(x, "data"). The alias is the only carrier of the name "data" at this stage (the Literal("data") field-name slot inside CreateNamedStruct is produced by CreateStruct.apply later, during ResolveFunctions). Once stripped, the resolved form becomes CreateNamedStruct(Seq(Literal("col1"), x)).

Design approach. Localized workaround in ExtractGenerator's Project case: trim only for AliasedGenerator pattern detection, and splice the original (untrimmed) e into the new project list. CleanupAliases at end-of-analysis still trims later, after ResolveFunctions has captured the alias name.

Concern -- the fix is local, the bug is in trimAliases. The same upfront .map(trimNonTopLevelAliases) exists in the sibling Aggregate-with-generator branch at Analyzer.scala:3211-3253, with the same case (other, idx) shape that propagates the trimmed other. The same struct-field-name regression is reachable for queries that route through that branch. More generally, the root cause is that trimAliases (and via it trimNonTopLevelAliases) descends into unresolved subtrees and strips aliases whose semantic role has not been determined yet -- UnresolvedFunction("struct", ...) is one case, but the pattern is broader.

Would you consider an alternate fix that addresses the timing issue directly in trimAliases? Adding a leading case e if !e.resolved => e clause would (a) cover the Aggregate path without a parallel edit, (b) leave the existing .map(trimNonTopLevelAliases) call sites in place, and (c) protect future callers that hand trimAliases a partially-resolved tree from the same trap. Curious whether you tried that direction and ran into issues, or whether the local fix was preferred for risk containment.